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Abstract 


This EIP adds a new transaction type of that includes expiration with a blocknum. 


Motivation 


When a user sends a transaction txe with a low gas price, sometimes it might not be 
high enough to be executed. A common resolution is for the user to submit the 
transaction again with the same nonce and higher gas price. 


That previous txe can theoretically be included in any time in the future unless a tx 
with the exact same nonce is already executed. 


When network is congested, gas price are high, for critical transactions user might try 
gas price that is much higher than an average day. This cause the txe choose might 
be very easy to executed in the average day. 
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If user already uses a tx1 with different nonce or from another account to execute 
the intended transaction, there is currently no clean way to cancel it, except for 
signing anew txe' that shares the same nonce but with higher gas fee hoping that 
it will execute to preempt- than txe. 


Given txe was already high gas price, the current way of preempting txe could be 
both unreliable and very costly. 


TODO(@xinbenlv): to include in the motivation: 


e Expiring transactions are transactions that have low time preference, but can 
easily become invalid in the future. For example, you may want to do a swap 
on an AMM but you don’t want to pay a very high fee for it so you set the 
max fee to a low number. However, your transaction will almost certainly fail 
if it takes longer than a couple minutes to be mined. In this scenario, you 
would rather fail cheaply if your transaction doesn’t get included quickly. 


Similarly, there are situations where there is a limited window of availability of 
some asset and if your transaction doesn’t mine within that period you know 
with certainty that it will fail. In these cases, it would be nice to be able to 
express that to the system and not waste unnecessary resources just to have 
the transaction fail. 


Specification 
The key words “MUST", “MUST NOT", “REQUIRED”, “SHALL”, “SHALL NOT", “SHOULD”, 


“SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to 
be interpreted as described in RFC 2119. 


Parameters 


e FORK BLKNUM = TBD 
e CHAIN ID = TBD 
e TX_TYPE = TBD, > 0x02 (EIP-1559) 


As of FORK_BLOCK_NUMBER , a new EIP-2718 transaction is introduced with 
TransactionType = TX_TYPE(TBD) . 


The intrinsic cost of the new transaction is inherited from EIP-2930, specifically 21000 
+ 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage 


key count + 2400 * access list address count . 


The EIP-2718 TransactionPayload for this transaction is 


rlp([chain_id, expire_by, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas limi 
> 
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The definition of expire_by is a block number the latest possible block to execute 
this transaction. Any block with a block number block_num > expire_by MUST NOT 
execute this transaction. 


The definitions of all other fields share the same meaning with EIP-1559 


The signature_y_parity, signature_r, signature_s elements of this transaction 
represent a secp256k1 signature over keccak256(@xe2 || rlp([chain_id, expire_by, 


nonce, max_priority_fee_per_gas, max_fee_per_gas, gas limit, destination, amount, 


data, access _list])). 


The EIP-2718 ReceiptPayload for this transaction is rlp([status, 


cumulative _transaction_gas_used, logs bloom, logs]) . 


Rationale 


TODO 


Backwards Compatibility 


TODO 


Security Considerations 
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4. 


If current_block_num is available, client MUST drop and stop 
propagating/broadcasting any transactions that has a transacton_type == 
TX_TYPE AND current_block_num > expire_by 


. It is suggested but not required that a currentBlocknum SHOULD be made 


available to client. Any client doing PoW calculation on blocks expire tx or 
propagating such are essentially penalized for wasting of work, mitigating 
possible denial of service attack. 


. It is suggested but not required that client SHOULD introduce a gossip_tt1 


in unit of block_num as a safe net so that it only propagate a tx if 
current_block_num + gossip_ttl <= expire_by . Backward compatibility: for 
nodes that doesn't have current_block_num or gossip_ttl available, they 
should be presume to be o. 


It is suggested by not required that any propagating client SHOULD properly 
deduct the gossip ttl based on the network environment it sees fit. 
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